[sdk-vpp#314] Add SR-IOV token ID mechanism parameter for kernel, VFIO mechanisms #110
Conversation
|
Question... the trick you are using here for SRIOVTokenID ... it generalizable to other non-SRIOV kinds of devices we may need to insert? I'm curious, because if it is we may want to pick more generic naming. To be specific, what I'm thinking is: there's a next gen thing coming down the line called SIOV (not SRIOV)... could we have a DeviceToken that is used for both SRIOV and SIOV (and whatever comes next after SIOV) or do we need to know that the Token is specific to SRIOV? |
Bolodya1997
force-pushed
the
sdk-vpp#314/token-id
branch
from
0cca414 to
1f5e958
Compare
Client/Endpoint uses SR-IOV token to reserve some VF on startup and then start using it after the Request. I suppose that introducing different type of devices may also contain some logic like this. |
| @@ -46,6 +48,10 @@ const ( | |||
| // PCIAddressKey - PCI address of the device for the SR-IOV supported mechanisms | |||
| PCIAddressKey = "pciAddress" | |||
|
|
|||
| // SRIOVTokenIDKey - Client/Endpoint SR-IOV token ID | |||
| // nolint:gosec | |||
| SRIOVTokenIDKey = "sriovTokenID" | |||
There was a problem hiding this comment.
Would it make sense to name this something more generic like 'DeviceToken' ... it seems like the trick you are using here could be used more broadly than SRIOV... do I have that right?
There was a problem hiding this comment.
We actually can do this, but it can possibly lead to the following behavior if there are not only SR-IOV tokens:
- Client requests kernel interface with
AAAdevice token. - Forwarder tries this token as a SR-IOV token - fails.
- Fails back to mechanism selection.
- Forwarder tries this token as a ... token - fails.
- ...
- Forwarder establishes the connection.
- Client makes refresh request.
- Forwarder tries this token as a SR-IOV token - fails.
- ...
So we can make a DeviceToken field instead of SRIOVDeviceToken one, but we may possibly need to add some IsDeviceTokenSRIOV in such case to avoid this confusion.
Signed-off-by: Vladimir Popov <vladimir.popov@xored.com>
Signed-off-by: Vladimir Popov <vladimir.popov@xored.com>
Bolodya1997
force-pushed
the
sdk-vpp#314/token-id
branch
from
1f5e958 to
e396b4c
Compare
| @@ -33,6 +35,9 @@ const ( | |||
| // PCIAddressKey - device PCI address property key | |||
| PCIAddressKey = common.PCIAddressKey | |||
|
|
|||
| // TokenIDKey is a token ID property key | |||
| TokenIDKey = common.TokenIDKey | |||
There was a problem hiding this comment.
Is this the Token we are getting from DevicePlugin in an ENV variable? If so, could we call it DeviceToken or DeviceTokenID?
Signed-off-by: Vladimir Popov <vladimir.popov@xored.com>
…i@main PR link: networkservicemesh/api#110 Commit: 9a36433 Author: Vladimir Popov Date: 2021-09-08 02:48:27 +0700 Message: - [sdk-vpp#314] Add SR-IOV token ID mechanism parameter for kernel, VFIO mechanisms (#110) * Add SR-IOV token ID mechanism parameter for kernel, VFIO mechanisms Signed-off-by: Vladimir Popov <vladimir.popov@xored.com> * Renam SR-IOV token ID to just token ID Signed-off-by: Vladimir Popov <vladimir.popov@xored.com> * Rename token ID to device token ID Signed-off-by: NSMBot <nsmbot@networkservicmesh.io>
Description
Adds SR-IOV token ID mechanism parameter for kernel, VFIO mechanisms.
Actually moves it from
sdk-sriovto more relevant place.https://github.com/networkservicemesh/sdk-sriov/blob/9a5f775aa79d492447aa58867b0a3218be78ff48/pkg/networkservice/common/resourcepool/common.go#L35-L36
Issue link
Needed for networkservicemesh/sdk-vpp#314.
How Has This Been Tested?
Types of changes